Subject: New Connect Flow for SNA

From: "Steve Klein" <[email-masked]>
Date: Tue, 11 Jan 94 21:33:30 EST

Here is my proposal for the separation of the topology establishment
and circuit establishment.  Your comments are welcome and encouraged.
I will send out a note with the NETBIOS flow shortly.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

This proposal introduces a new type of CANUREACH and ICANREACH message.
A CANUREACH_ex message is a CANUREACH message only for the purpose
of maintaining topology information for real and virtual MAC addresses
in the DLSw network.  The response to a CANUREACH_ex is an ICANREACH_ex.

A CANUREACH_cs is a circuit-setup CANUREACH and is equivalent in function
to the existing CANUREACH documented in RFC 1434.  A CANUREACH_cs implies
that a DLSw circuit is to be established.  The response to a CANUREACH_cs
is a ICANREACH_cs.

A CANUREACH_ex is differentiated from a CANUREACH_cs by the presence of a
B'1' in the first bit position of a new 'flags' field in the SSP message
header.  This 'flags' field would be replace the previously 'reserved'
field that follows the 'message type' field in both SSP headers.  The
ICANREACH_ex will have the same bit set.

The CANUREACH_cs and ICANREACH_cs will have the same format as the
CANUREACH from RFC 1434 for compatibility with RFC 1434 DLSw
implementations.  A 'standard' DLSw that receives a ICANREACH_cs in
response to a CANUREACH_ex could imply that it is communicating with
an RFC 1434 DLSw and should setup a circuit.

Advantages of this new approach:

  Prevents setup of a extra circuit for unequal SAP connections.
  The 'logical guess' that the destination SAP will equal the source SAP
  will no longer have to be made since the first non-broadcast frame will
  contain the origin station's source SAP.

  Prevents multiple CANUREACHs (and multiple circuits) during
  connection setup when connection is preceded by TEST frames.

-----------------------------------------------------------------------------

New Connection Sequence: Token Ring SNA

   ======                            ___                           ======
   |    |        ---------        __/   \__       ---------        |    |
   |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
   ======        |   |   |      <  Network  >     |   |   |        ======
  /______\       ---------       \__     __/      ---------       /______\
                Origin DLSw         \___/        Target DLSw
   Origin         partner                          partner         Target
   Station                                                        Station

                DISCONNECTED                    DISCONNECTED
TEST_cmd                       CANUREACH_ex                    TEST_cmd
----------->                   ------------>  SEARCH_PENDING   ----------->   Note 1
   .                                                              .
   .                                                              .
TEST_cmd                                                       TEST_cmd
-----------> drop until we respond                   T1 retry  ----------->   Note 2

     TEST_rsp                     ICANREACH_ex                       TEST_rsp
 <-----------                    <------------    DISCONNECTED   <-----------

XID_cmd                        CANUREACH_cs                    TEST_cmd
----------->                   ------------>  RESOLVE_PENDING  ----------->   Note 3
   .
   .
XID_cmd
-----------> drop until we respond                                            Note 4

                                  ICANREACH_cs                       TEST_rsp
             CIRCUIT_ESTABLISHED <------------  CIRCUIT_PENDING  <-----------
    TEST_cmd
 <----------                                                                  Note 5
TEST_rsp
---------->                    REACH_ACK
                               ------------>   CIRCUIT_ESTABLISHED
                                   XIDFRAME                    XID_cmd        Note 6
                               ------------>                   ----------->
     XID_rsp                       XIDFRAME                           XID_rsp
 <----------                     <------------                   <-----------

    XID                          XIDFRAME                         XID
<---------->                   <------------->                  <---------->

SABME/SNRM
----------->  CONNECT_PENDING
          UA                   CONTACT                         SABME/SNRM
 <----------                   ------------>  CONTACT_PENDING  ----------->
RR
----------->  (link station in local busy state)
          RNR
 <-----------                        CONTACTED                             UA
                  CONNECTED     <-------------     CONNECTED    <------------
RR            (link station taken out of local                 RR
----------->      busy state)                                  ------------>
           RR                                                              RR
 <-----------                                                   <------------

   IFRAME                          IFRAME                          IFRAME
<---------->                    <----------->                   <---------->

Note 1: A TEST frame (broadcast) generates the new explorer CANUREACH
        in the origin DLSw partner.  If the target DLSw has cached
        information about the target MAC address, it responds with the
        new explorer ICANREACH.  Otherwise, it sends out a TEST frame
        and goes into a new 'search only' state, SEARCH_PENDING.

Note 2: Retries of the TEST frame on the origin side are not propagated
        across the WAN.  Retries are performed by the target side.

Note 3: The first non-broadcast frame is received by origin partner so
        a circuit-setup CANUREACH is sent.  The CANUREACH_cs target
        SAP is set to the destination SAP from the non-broadcast frame.
        The CANUREACH_cs causes a DLC_START_DL in the target partner
        resulting in a TEST frame and a state transition to RESOLVE_PENDING.
        An DLC implementation that does not require a TEST_cmd/TEST_rsp
        exchange could make a transition directly into CIRCUIT_PENDING
        state.

Note 4: Retries of the XID are dropped while the circuit setup take place.
Note 5: Upon receipt of the ICANREACH_cs the origin partner starts a
        link station instance.  An implementation may optionally send a
        TEST_cmd when the station is started (like the 6611, for instance).

Note 6: The XID that started the circuit setup is sent to the target
        partner in an XIDFRAME.  An implementation may choose to send the
        original XID or wait for the next retry that comes in after the
        ICANREACH_cs is received.
-----------------------------------------------------------------------------

---

From: Frank Bordonaro <[email-masked]>
Date: Mon, 28 Feb 94 19:10:18 PST

I apologize for the dealyed response to the "New Connect Flow for SNA" 
proposal by Steve Klien. Steve's note is attached at the end of this reply.

I have several issues with the proposal.

 1. The DLC flow depicted in the proposal does not scale well.
 
    Steve's proposal introduces several extra DLC TEST frames that are 
    totally unnecesary. The main goal of the original proposal is to 
    prevent the setup of an extra circuit for unequal SAP connections. I 
    support the introduction of the CANUREACH_ex and ICANREACH_ex messages 
    for this end, but would like to see an optimal DLC flow describing the 
    circuit setup.

    I understand that as long as the SSP flow is RFC comliant, it does not really
    matter what a vendor does on the DLC side. However, some vendors at the RIGlet
    were asking for a mapping of DLC events to SSP messages and I would like to see
    these mappings shown as best case implementation. 

 2. The connect flow does not take into account (probably prohibits) the 
    tunneling of sdlc to sdlc.

    For sdlc to sdlc, XID then SNRM(E), or simpy SNRM(E) will flow to 
    establish the connection. So, when a switch recieves an SSP CANUREACH, 
    how does it know whether to send out a TEST, XID, or SNMR(E)? In today's
    SSP format, it has no way of knowing. I propose that both flavors of
    CANUREACH and ICANREACH (ex and cs) contain the DLC header and frame data.
    This allows for an XID or SNRM(E) to trigger the connection. Also, this
    allows switches to participate in the Largest Frame Size negotiation in
    TR to TR. 

 3. On the initial CANUREACH_ex, the target switch goes into SEARCH_PENDING
    state and sends a TEST_cmd when the t1 timer expires. When does this stop?
    There needs to be either a timer or a max number of TESTs that are sent before
    the target swicth returns to the DISCONNECTED state. By the same token, if no
    ICANUREACH_ex's are received, the origin switch must eventually stop dropping 
    TESTs and send out another round of CANUREACH_ex's. Again, this can be timer 
    or number based.

    I have not thought about the following idea long enough to propose it, but it 
    may be good food for thought. What do you think about allowing TESTs and XIDs 
    to flow end to end, without dropping them on the origin side and proxy sending
    them on the target side? The origin switch would generate a CANUREACH_ex for 
    each Nth TEST (XID)  it receives (N could be something like 5) and drop all 
    others. Without the SEARCH_PENDING state, the target switch could still keep 
    track of unanswered TESTs. The target switch only sends out a TEST when it 
    receives a CANUREACH_ex. This avoids the T1 retry and give-up logic that we 
    would need to design. This is not a bad idea as long as the rate the origin 
    switch receives TESTs times N, is greater than the round trip delay. N could 
    have a default, but be adjusted based on TCP round trip time.

Scalable Connect Flow 
=====================

There are 3 changes shown in the flow below with respect to Steve's original 
proposal. The first is the optimal DLC flow; no extra TESTs. The second is the 
addition of DLC header and data to CANUREACH and ICANREACH messgaes. The third 
change is the exploratory idea of making TESTs (and XIDs) end to end as discussed
in item 3 above.

Please note, XXXXREACH_xx(frame) indicates the "frame" that triggered the
XXXXREACH_xx is concatenated to the XXXXREACH_xx message.

   ======                            ___                           ======

                DISCONNECTED                    DISCONNECTED
TEST_cmd                   CANUREACH_ex(TEST_cmd)             TEST_cmd
----------->                   ------------>                   -----------> Note 1  
   .  
TEST_cmd     drop TEST 1                                      (no resp to test)
TEST_cmd     drop TEST 2 
   .
TEST_cmd     send TEST N   CANUREACH_ex(TEST_cmd)             TEST_cmd
----------->                   ------------>                   -----------> Note 1

     TEST_rsp              ICANREACH_ex(TEST_rsp)                  TEST_rsp
 <-----------                    <------------    DISCONNECTED   <-----------
 
XID_cmd                    CANUREACH_cs(XID_cmd)               XID_cmd
----------->                   ------------>  RESOLVE_PENDING  ----------->   
 
Note 2
                           ICANREACH_cs(XID_rsp)                   XID_rsp
             CIRCUIT_ESTABLISHED <------------  CIRCUIT_PENDING  <-----------
    XID_rsp
 <----------                                                                
                               REACH_ACK
                               ------------>   CIRCUIT_ESTABLISHED
    XID                          XIDFRAME                         XID
<---------->                   <------------->                  <---------->
 
SABME/SNRM
 
   IFRAME                          IFRAME                          IFRAME

Note 1: The target switch knows to send a DLC TEST_cmd in response to receiving
        an SSP CANUREACH_ex(TEST_cmd), because it can find the originating DLC 
        TEST_cmd frame at the end of the SSP CANUREACH_ex message. Similarly, for 
        all other CANUREACH/ICANREACH messages received above. 

Note 2: Send Nth XID_cmd in a CANUREACH_cs(XID_cmd), not shown. 

=================================================================================
=================================================================================

Received: by ibmstandards.cary.ibm.com (5.61-AIX-1.2/1.0) from [192.239.48.4] with S
MTP
        id AA111001; Tue, 11 Jan 94 21:29:40 -0500
Message-Id: <[email-masked]>
Received: from RALVMA by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 7569;
   Tue, 11 Jan 94 21:41:42 EST
Date: Tue, 11 Jan 94 21:33:30 EST
From: "Steve Klein" <[email-masked]>
To: [email-masked]
Subject: New Connect Flow for SNA

 

 

 

 
   ======                            ___                           ======

 
 
                                  ICANREACH_cs                       TEST_rsp
 
    XID                          XIDFRAME                         XID
 
SABME/SNRM
 
   IFRAME                          IFRAME                          IFRAME

---

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 1 Mar 1994 10:23:00 +0000

In message "Re: New Connect Flow for SNA", 

>    allows switches to participate in the Largest Frame Size negotiation in

This proposal would support sdlc to sdlc, but not trn to sdlc.  The purpose
of the CANUREACH_ex is to locate the attachment point of a particular MAC
address.  For an SDLC station the MAC address exists only as a configured
option of the interface.  It would therefore be permisseable, and perhaps in
some situations desireable, for the adaptation layer to respond to the
CANUREACH_ex without first verifying that the associated SDLC device is
operational.  Strange as this behavior might seem, it is not completely
foreign to the LLC behavior of a TRN device.  For example the fact that a
particular MAC can respond to a TEST frame directed at SAP 0, the normal
case, does not imply that that MAC can respond to an XID or SABME directed at
some other SAP, for example SAP 04.  Therefore a CANUREACH_ex directed at a
particular MAC may succeed even though a subsequent CANUREACH_cs will fail
(time-out).  I therefore suggest that having the sdlc adaptation layer respond
to CANUREACH_ex without taking any action on the link is acceptable, and
certainly the simplest implementation.  Involving TEST frames, which have
never been part of the connection establishment process on SDLC lines, is
definitely unnacceptable.

As for CANUREACH_cs, which I feel does require communicating with the
attached device the action to take is implementation dependent, and therefore
will require configuration options in the sdlc adaptation layer.  If the
attached device is an SDLC secondary or configurable then a null XID will
work almost all of the time, but we are all familiar with the exceptional
devices which do not generate a link level response to an XID.  Such devices
require a considerable quantity of configuration data, sufficient to permit
constructing an XID3 response on behalf of the dumb device.  However before
generating such a response it is essential to first determine if the device
is operational, in this case by sending SNRM.  For such a device it must then
be recorded that it is already in NRM, so the CONTACTED response is generated
by the sdlc adaptation layer without any action on the link.

In conclusion I can see no value in carrying any DLC frame information in the
CANUREACH and ICANREACH messages.

>    state and sends a TEST_cmd when the t1 timer expires. When does this stop?

The fundamental concern is that, in all likelihood, some
other DLSw has already discovered the destination, so any extensive
repetition of the TEST is a waste of time.  However if everyone gives up too
soon, then the location of the destination will not be discovered.

The RFC discusses what happens when one or more than one ICANREACH is
received, but not what happens when no response is received.  However since
there is no state change on receipt of "TEST" from the link and the
transmission of CANUREACH[_ex] I must presume that the origin DLSw will send
out a CANUREACH every time it receives a "TEST".  This in turn will cause
each of the DLSws which receive the CANUREACH to repeat the route discovery.
In this case it is not necessary for the receiver of CANUREACH_ex to send
more than one "TEST".  As soon as one or more ICANREACH_ex responses are
received, the origin DLSw will stop sending CANUREACH_ex and the route
discovery process on all other DLSws stops immediately.  When the t1 timer
expires on the transmission of "TEST" the other DLSws simply return to
DISCONNECTED state rather than locally retransmitting the "TEST".

I put "TEST" in quotes because it is only a TEST frame on a TRN.

---

From: Frank Bordonaro <[email-masked]>
Date: Tue, 1 Mar 94 10:23:32 PST

> constructing an XID3 response on behalf of the dumb device. 

    There are two issues. The first is knowing end to end info carried in XIDs. 
    The second is knowing which frame on the other side triggered the SSP message,
    or in what stage of circuit set up the other end station is in.
 
    I disagree that the best we can do is to have the customers provide  
    "considerable quantity of configuration data". 
    Secondly, not knowing the DLC events during CANUREACH/ICANREACH will force
    switches to make assumptions, rather than react to actual situations. 

> However before

Here is a TRN situation where it may be helpful to carry the DLC frame in the
CANUREACH and ICANREACH messages.
 
   ======                            ___                           ======
 
                DISCONNECTED                    DISCONNECTED
TEST_cmd
----------->   This switch just received an SSP ICANREACH for the target
               MAC address so there is no need to send another ICANREACH.
               Respond locally to the TEST.
     TEST_rsp
 <-----------
 
XID_cmd                        CANUREACH_cs                    ????????
----------->                   ------------>  RESOLVE_PENDING  ----------->
 
?????? : How does the target switch know which frame to send on the link?
 
If the switches' RIF caches are in synchronization, the target switch could
recognize that and send an XID. But that may not be a small "if".
Or the target switch could always send a TEST, which is not optimal.
For the price of some extra bytes at the end of the already inflated SSP
message, it seems worth gaining the extra knowledge. 

How do you see the switches coordinating the largest frame size negotiation 
if they terminate the XID info? Do this info get added to the SSP header? 
If not, does anyone plan to fragment frames?

I think the extra knowledge is even more critical in the sdlc 2.0 example below.

SDLC to SDLC PU 2.0 Connection Sequence
 
   ======                            ___                           ======
 
                DISCONNECTED                    DISCONNECTED
SNRM                           CANUREACH_ex                    
----------->                   ------------>  NO Search as prosed above
                                              Look up phony sdlc mac in config
       Send No Resp to Link       ICANREACH_ex                  
                                 <------------    DISCONNECTED 
 
SNRM                           CANUREACH_cs                    ???????
----------->                   ------------>  RESOLVE_PENDING  ----------->

??????? : How does the target switch know which frame to send on the link?
          An XID? An SNRM? 

If this was a 2.1 start up with an XID flow, how does the target switch know
the ID Block/Num and other info to put in the XID?